home *** CD-ROM | disk | FTP | other *** search
- Path: hermes.oc.com!usenet
- From: Larry Weiss <lfw@oc.com>
- Newsgroups: comp.lang.c
- Subject: Re: Borland C - compiler not finding window.h file.
- Date: Fri, 09 Feb 1996 10:56:44 -0600
- Organization: OpenConnect Systems, Dallas, TX, USA
- Message-ID: <311B7CCC.6BFD@oc.com>
- References: <4f85f9$4i8@guitar.sound.net> <311AAC3C.3DB@ix.netcom.com>
- NNTP-Posting-Host: ocs2228.oc.com
- Mime-Version: 1.0
- Content-Type: text/plain; charset=us-ascii
- Content-Transfer-Encoding: 7bit
- X-Mailer: Mozilla 2.0 (Win16; I)
- CC: lfw@oc.com
-
- Norman Bullen wrote:
-
- > Do you have <...> or "..." surrounding the include file name? <...> will
- > find the file in any of the directories specified in the IDE for include
- > files; "..." will only find the file in the current directory or a fully
- > qualified directory.
-
- It's up to the specific implementation to define the exact rules that
- define any definition of a path to search, but the usual definition
- for the "..." syntax is more complex than you describe. The usual
- rule is that if possible, the included file is the one that is in the
- same directory as the file in which the #include directive is found.
- Only if that rule is not possible (the file does not exist in that
- directory) does the file in the current directory get included.
-
- This has grave consequences for nested include files, and sometimes
- you get different versions of the same include files used in different
- modules of a program. Because of this, I never use the "..." form
- and always use the <...> form. The <...> form usually is associated
- with a rule that defines and uses a user defineable and predictable search
- path (that can include the current directory, if desired, as the first
- directory to search).
-
- Again, these are strictly implementation (not language) issues.
-